Common Methods And Tool Recommendations For Performance Testing On Tencent Cloud Servers In Singapore IDC Computer Rooms

2026-08-09 10:25:59
Current Location: Blog > Singapore server
Singapore Server

1.

Overview: Why it is important to do performance testing on Singapore IDC

· Objective: Verify the stability and throughput capabilities of Tencent Cloud (Singapore region) CVM in Asia-Pacific access scenarios.
·Scope: Including network bandwidth, TPS/RPS, latency, system resources (CPU/memory/IO) and database performance.
· Scenarios: Typical scenarios such as e-commerce flash sales, interface concurrency, and high concurrent downloads of static sites.
· Indicators: Throughput rate (RPS/TPS), average/median/95/99 latency, CPU/memory peak, packet loss and retransmission rate.
· Methodology: Layered testing (network layer -> system layer -> application layer -> DB layer), first without CDN/protection direct connection, and then add middleware to verify the effect.

2.

Common load generation tools and usage scenarios

· ApacheBench (ab): lightweight HTTP concurrency test, often used to quickly verify RPS. Example: ab -n 50000 -c 200 http://ip/
· wrk: supports multi-threading, suitable for long-term stress testing and Lua script scenarios, example: wrk -t4 -c400 -d60s http://ip/
· siege: Supports URL list and duration stable stress testing, suitable for simulating multi-interface mixed loads.
· JMeter: GUI/non-GUI mode, supports complex business scripts, assertions, distributed stress testing and monitoring data collection.
· Gatling: Scala script, suitable for performance regression testing in continuous integration pipelines.

3.

Network and bandwidth testing tools (iperf3, etc.) and CDN/DDoS considerations

· iperf3: Measure pure transport layer bandwidth, bidirectional test. Example: iperf3 -s (server); iperf3 -c server_ip -P8 -t30 (client).
· netperf: used for TCP/UDP throughput and latency, suitable for fine-grained network benchmarks.
· CDN verification: First connect directly to the server as a baseline, then enable Tencent Cloud CDN to observe changes in edge hit rate and back-to-source bandwidth.
· DDoS protection: After turning on Tencent Cloud Protection (Anti-DDoS), please note that the combined traffic cleaning will affect the observation, and traffic mirroring testing needs to be done outside the cleaning node.
· Indicators focus on: bandwidth usage, packet loss rate, RTT, TCP retransmission, connection establishment time (SYN to ACK).

4.

System and database stress testing and monitoring tools

· sysbench: used for CPU, memory, fileio, and OLTP benchmarks. Example: sysbench --test=cpu --cpu-max-prime=20000 run.
· mysqlslap / sysbench oltp: Test MySQL’s TPS and transaction latency under multi-concurrency.
· dstat / sar / iostat: Monitor disk IO, network, CPU load, and context switching. It is recommended to cooperate with stress testing for real-time collection (every 5 seconds).
· top/htop/perf: used to locate hot threads and system call bottlenecks.
· Logs and APM: Collect application logs, NGINX access logs, and use SkyWalking/Prometheus+Grafana for trend analysis.

5.

Real cases and server configuration examples (including test data)

· Background: A regional e-commerce company deployed front-end and API services in Tencent Cloud Singapore IDC, with a target peak concurrent request rate of 10k requests/s.
· Initial CVM configuration (example): 4 vCPU, 8GB RAM, 100GB SSD, 200Mbps bandwidth (priced per bandwidth), Ubuntu 20.04.
· Test steps: First perform a wrk stress test on the API (direct connection), and then return the same traffic to the source via CDN; at the same time, use iperf3 to measure the bandwidth limit.
· Test command example: wrk -t4 -c1000 -d60s http://cvm_ip/api/endpoint; iperf3 -c server_ip -P8 -t30.
·Result display (aggregated value):
Testing tools Throughput (RPS/TPS) p50 delay (ms) p95 delay (ms) CPU peak (%)
wrk (direct connection) 4,200 35 120 78
wrk (enable CDN back-to-origin) 3,900 28 95 62
iperf3 bidirectional Bandwidth: 180 Mbps RTT: 12 ms Network CPU: 30

6.

Tuning suggestions, processes and common pitfalls

· Tuning order: Network->System parameters->Application (nginx/java/mysql)->Horizontal expansion/CDN cache.
· Common kernel tuning examples: sysctl -w net.core.somaxconn=10240; sysctl -w net.ipv4.tcp_tw_reuse=1.
· Nginx tuning reference: worker_processes auto; worker_connections 65536; keepalive_timeout 15.
· Database optimization: increasing the connection pool, optimizing slow query indexes, sharding databases and tables or separating reading and writing, and using Tencent Cloud DBCDB/CMysql to enhance stability.
· Common misunderstandings: 1) Fully loaded single-machine CPU does not mean that the system cannot be expanded; 2) Low CDN hit rate will mislead the judgment of back-to-origin performance; 3) DDoS cleaning accidentally damages normal traffic and requires communication with operation and maintenance.

7.

Conclusion and implementation suggestions

· It is recommended to normalize: include the stress test script into CI, conduct regression stress test and save baseline data before release.
·Monitoring alarms: Combine with Prometheus/Grafana to set CPU/RTT/error rate and other threshold alarms.
· Disaster recovery and elasticity: Use Tencent Cloud CLB+Auto Scaling and multi-AZ deployment to improve availability.
·Evidence: All key tests must retain commands, original logs, and monitoring charts as a basis for capacity planning.
· Contact point: If you encounter regional link problems, it is recommended to contact Tencent Cloud technical support and provide iperf3 and packet capture results for easy location.

Related Articles